Improve parsing of plugin arguments in target-query#1619
Improve parsing of plugin arguments in target-query#1619
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1619 +/- ##
==========================================
+ Coverage 81.10% 81.13% +0.02%
==========================================
Files 401 401
Lines 35175 35185 +10
==========================================
+ Hits 28529 28546 +17
+ Misses 6646 6639 -7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
750b9ea to
3c8b561
Compare
|
Perhaps this makes implementing #1493 easier. |
| return 0 | ||
|
|
||
| # Dynamically add plugin arguments for the specified function(s) | ||
| for func_desc in find_and_filter_plugins( |
There was a problem hiding this comment.
Can we cache the results of this Never mind, we do not have find_and_filter_plugins call so it doesn't have to be called again later on?Target context here.
There was a problem hiding this comment.
I didn't spend much time on figuring out what find_and_filter_plugins all does, so i'm also not sure if target=None will have any effect of some plugins being returned or not.
|
Windows tests are failing due to windows_path vs posix_path. will look into it later. |
788599e to
9b53c3c
Compare
This PR implements the suggested solution described in #1508, the described edgecase is left open.
It mainly gets the supported argparse arguments from the requested plugins to
target-query, and then reparses the arguments again so it properly parses known plugin flags. This essentially fixes the problem described in the issue.Unknown arguments/flags now also throw an error, which before would go unnoticed.
resolves #1508, #1362